FIG. 1 illustrates an example Long Term Evolution (LTE) architecture. The example architecture of FIG. 1 includes a plurality of radio access nodes, such as evolved NodeBs (eNBs), Home eNBs (HeNBs) and an HeNB gateway (HeNB GW). The LTE architecture shown in FIG. 1 also includes evolved packet core (EPC) nodes, such as Mobility Management Entities (MMEs) and Serving-Gateways (S-GWs). FIG. 1 further illustrates the logical interfaces between the various nodes. As shown in the example of FIG. 1, the eNBs and HeNBs interface over an X2 interface, and the eNB/HeNBs interface with the MME/S-GW/HeNB GW over an S1 interface. In other words, an S1 interface connects HeNBs/eNBs to the MME/S-GW and HeNBs to the HeNB GW, while an X2 interface connects peer eNBs/HeNBs, optionally via an X2 GW. The radio access nodes may communicate wirelessly with user equipment (UEs) (not shown).
FIG. 2 illustrates an exemplary management system architecture. In the example of FIG. 2, the node elements (NE) (also referred to, for example, as eNBs) are managed by a domain manager (DM) (also referred to as the operation and support system (OSS)). A DM may further be managed by a network manager (NM). Two NEs are interfaced by X2, whereas the interface between two DMs is referred to as Itf-P2P. The management system may configure the network elements, as well as receive observations associated to features in the network elements. For example, the DM observes and configures NEs, while the NM observes and configures the DM, as well as NE via DM. By means of configuration via the DM, NM and related interfaces, functions over the X2 and S1 interfaces may be carried out in a coordinated way throughout the RAN, eventually involving the Core Network (i.e., MME and S-GWs).
The overall principles of the various embodiments described herein would work for both an LTE-like architecture and a new architecture based on an evolution of the S1 interface (e.g., an architecture with evolved counterparts of the S1, X2 and Uu interfaces and which further provides that any new radio access technology (RAT) would be integrated with the LTE radio interface at radio access network (RAN) level in a similar fashion as the way LTE Dual Connectivity (DC) is defined). An example of an evolved architecture is a 5G architecture.
The S1 Control Plane interface is defined between MME and eNB, and is described in the Third Generation Partnership Project (3GPP) specifications TS 36.300, TS 36.410, TS 36.411, TS 36.412 and TS 36.413.
FIG. 3 illustrates an exemplary control plane stack. The control plane stack of FIG. 3 includes a physical layer 302, a data link layer 304, an Internet Protocol (IP) layer 306, a Stream Control Transmission Protocol (SCTP) layer 308, and an S1 Application Protocol (S1AP) layer 310. In the example of FIG. 3, the transport network layer 306 is based on IP transport. On top of IP layer 306, SCTP layer 308 is added for reliable transport of signaling messages.
Only one single SCTP association is established between one MME and eNB pair. Within the SCTP association established between one MME and eNB pair, one single pair of stream identifiers is reserved for the sole use of S1AP elementary procedures that utilize non UE-associated signaling, and at least one (and up to a few) pair(s) of stream identifiers are reserved for the sole use of S1AP elementary procedures that utilize UE-associated signaling. Also, single UE-associated signaling uses one SCTP stream and the stream should not be changed during the communication of the UE-associated signaling.
FIG. 4 illustrates a state transition diagram of S1AP. More particularly, FIG. 4 illustrates transitions between two states, S1AP CONNECTED state 402 and S1AP DISCONNECTED state 404. In case the SCTP layer (e.g., SCTP layer 308 described above in relation to FIG. 3) notifies the S1AP layer (e.g., S1AP layer 310 described above in relation to FIG. 3) that the signaling connection broke, the entire S1AP will then be reset on both endpoints. In other words, the MME locally changes the state of the UEs that used this signaling connection to the ECM-IDLE state, and the eNB releases the Radio Resource Control (RRC) connection with those UEs. This is reflected in the state diagram as arrow 406 from S1AP CONNECTED state 402 to S1AP DISCONNECTED state 404 with action “Broken lower layer.”
As shown in the example of FIG. 4, transitions from S1AP DISCONNECTED state 404 to S1AP CONNECTED state may be achieved via an S1 setup procedure, reflected in the state diagram as arrow 408 from S1AP DISCONNECTED state 408 to S1AP CONNECTED state 402 with action “S1 Setup.” Similarly, the S1 Setup procedure may take place within S1AP CONNECTED state 402, reflected in the state diagram as arrow 410 from S1AP CONNECTED state 402 to S1AP CONNECTED state 402 with action “S1 Setup.” The S1 setup procedure is described in more detail below in relation to FIG. 5.
FIG. 5 illustrates an example of a successful S1 setup procedure. More particularly, FIG. 5 illustrates a signal-flow diagram between an eNB 105 and an MME 130. At step 502, eNB 105 sends an S1 Setup Request message to MME 130. At step 504, MME 130 sends an S1 Setup Response message to eNB 105.
During the S1 setup procedure illustrated in FIG. 5, the endpoints (MME 130 and eNB 105) will erase all existing application level configuration data and replace it by the configuration data received in the procedure. This procedure also re-initializes the E-UTRAN S1AP UE-related contexts (if any) and erases all related signaling connections for the endpoints. This is reflected in the state diagram of FIG. 4 (described above) as arrow 408 from S1AP DISCONNECTED state 404 to S1AP CONNECTED state 402 with action “S1 SETUP” (in case of no application level configuration data, or transport layer has been broken before), or arrow 410 from S1AP CONNECTED state 402 to S1AP CONNECTED state 402 with action “S1 SETUP” (in case of previous application level configuration data and transport layer is not broken).
Currently, there is no procedure to tear down a S1AP connection. In practice this means S1AP can be torn down only by breaking the signaling connection. This is reflected in the state diagram of FIG. 4 (described above) as arrow 406 from S1AP CONNECTED state 402 to S1AP DISCONNECTED state 404 with action “Broken lower layer.”
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. This protocol is defined in IETF Request for Comments (RFC) 4960. SCTP offers the following services to its users: acknowledged error-free non-duplicated transfer of user data; data fragmentation to conform to discovered path Maximum Transmission Unit (MTU) size; sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages; optional bundling of multiple user messages into a single SCTP packet; and network-level fault tolerance through support of multi-homing at either or both ends of an association. The design of SCTP also includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.
FIG. 6 illustrates an example SCTP association initialization procedure. More particularly, FIG. 6 is a signal-flow diagram of an initialization of SCTP association between endpoints (client 602 and server 604). At step 606, client 602 sends an initialization (INIT) message to server 604. At step 608, server 604 sends an initialization acknowledgement message (INIT-ACK) message to client 602. At step 610, client 602 sends a COOKIE-ECHO message to server 604. At step 612, server 604 sends a COOKIE-ACK message to client 602.
During the four-way handshake performed during initialization, the following SCTP specific information exchange between the endpoints (i.e., client 602 and server 604) is mandatory. The exchanged information includes an initiated tag, an advertised receiver window credit, a number of outbound streams, a number of inbound streams, an initial transmission sequence number (TSN); and a state cookie.
The Initiated Tag is used for packet validation of the SCTP session. A tag value (initial tag) is chosen by each end of the association during association initialization. This value will be assigned to field “Verification Tag” on all upcoming packets. Packets received without the expected Verification Tag value in the session are discarded, as a protection against blind masquerade attacks and against stale SCTP packets from previous sessions.
The Advertised Receiver Window Credit parameter represents the dedicated buffer space, in number of bytes, the endpoints have reserved in association with this window. During the life of the association, this buffer space should not be lessened (i.e., dedicated buffers taken away from this association).
The number of outbound streams defines the number of outbound streams the sender endpoint wishes to create in this association. The final number of outbound streams will be the minimum value of “Number of Outbound Streams” from the sender endpoint and the “Number of Inbound Streams” from the receiver endpoint.
The number of inbound streams defines the maximum number of streams the sender endpoint allows the peer end to create in this association. The final number of inbound streams will be the minimum value of “Number of Inbound Streams” from the sender endpoint and the “Number of Outbound Streams” from the receiver endpoint.
The Initial TSN is the initial TN of the sender of the association.
The state cookie is used for session authentication for protection against attack.
For multi-homing, in the current SCTP standard, multiple transport addresses on the end-points can be setup during the association initialization procedure. Modification of addresses after SCTP establishment can be done with an INIT message and a new address list parameter, the receiving endpoint responds with an ABORT message with cause of error “restart of an association with new addresses.” The signal flow for address changes is described in more detail below in relation to FIG. 7.
FIG. 7 illustrates an example of address changes on an existing association. More particularly, FIG. 7 is a signal-flow diagram of an address change between endpoints (Endpoint A 702 and Endpoint Z 704). At step 706, Endpoint A 702 sends an INIT message to Endpoint Z 704. The INIT message includes a new address list parameter (reflected in the example of FIG. 7 as “address list=<differ from previous INIT/INIT-ACK>”). At step 708, Endpoint Z 704 sends an ABORT message to Endpoint A 702. The ABORT message includes a cause of error “restart of an association with new addresses” (reflected in the example of FIG. 7 as “Error Cause=“Restart of an association with new addresses”).
FIG. 8 illustrates a simplified SCTP association termination procedure. More particularly, FIG. 8 illustrates an example graceful termination of SCTP association between endpoints (Endpoint A 802 and Endpoint Z 804). In the example of FIG. 8, Endpoint A 802 wants to terminate the association. Endpoint A 802 will stop accepting new data from its upper layer, and wait (and retransmit outstanding data if needed) until all outstanding data has been acknowledged by Endpoint Z 804. At step 806, Endpoint A 802 transmits a SHUTDOWN chunk to Endpoint Z 804.
When Endpoint Z 804 receives SHUTDOWN chunk transmitted by Endpoint A 802, Endpoint Z 804 will stop accepting new data from its upper layer, and wait (and retransmit outstanding data if needed) until all outstanding data has been acknowledged by Endpoint A 802. At step 808, Endpoint Z 804 transmits a SHUTDOWN-ACK chunk to Endpoint A 802.
When Endpoint A 802 receives the SHUTDOWN-ACK chunk transmitted by Endpoint Z 804, Endpoint A 802 will remove all record of the association, and, at step 810, transmit a SHUTDOWN-COMPLETE chunk to Endpoint Z 804. When Endpoint Z 804 receives SHUTDOWN-COMPLETE chunk transmitted by Endpoint A 802, Endpoint Z 804 will remove all record of the association.
Network slicing relates to the creation of logically separated partitions of the network. Each network slice may, for example, address different business purposes. These “network slices” are logically separated to a degree that they can be regarded and managed as networks of their own.
The concept of network slicing applies to both LTE Evolution and new 5G RAT (also referred to as “NR” herein). A key driver for introducing network slicing is business expansion, such as improving the cellular operator's ability to serve other industries (e.g., by offering connectivity services with different network characteristics, such as performance, security, robustness, and complexity).
FIG. 9 illustrates an example of network slicing. An example of an architecture with network slicing provides a shared RAN infrastructure that will connect to several EPC instances (e.g., one EPC instance per network slice). As the EPC functions are virtualized, an operator may instantiate a new Core Network (CN) when it is determined that a new slice should be supported. In the example architecture of FIG. 9, slice 0, for example, may be a Mobile Broadband slice and Slice 1, may, for example, be a Machine Type Communication (MTC) network slice.
Because only one single SCTP association can be established between an eNB and MME, problems are encountered, for example, in connection with a hardware swap, or a single UE handling failure, which may cause a domino-effect crash of SCTP.